As described in #893, the button block text color setting isn't working with the editor palette classes. This PR fixes that issue.

The root of the problem is that the .has-x-color styling is being overwritten by color: inherit being applied to the button element with higher specificity. In the theme, we can fix this by updating the targeting to :not(.has-text-color), which this PR does.

However, the core block editor styles (output on the front-end) includes the following CSS:

.wp-block-button__link:active, .wp-block-button__link:focus, .wp-block-button__link:hover, .wp-block-button__link:visited {
    color: inherit;
}

Which also overwrites the .has-x-color class, applied to the .wp-block-button__link element. I couldn't see any solution to this other than reapplying all of the .has-x-color classes to this element specifically, with a specificity high enough that it overwrites the color: inherit block above. So this PR adds the following:

.wp-block-button__link.has-accent-color {
	color: #cd2653;
}

.wp-block-button__link.has-primary-color {
	color: #000;
}

.wp-block-button__link.has-secondary-color {
	color: #6d6d6d;
}

.wp-block-button__link.has-subtle-background-color {
	color: #dcd7ca;
}

.wp-block-button__link.has-background-color {
	color: #f5efe0;
}

Along with corresponding updates to the targeting in twentytwenty_get_elements_array. This is an ugly solution, but I don't see another way of overruling the color: inherit set in the core styles.

Edit: Updated the solution per this suggestion by @m-e-h, which brings it more in line with how core handles the specificity of the color classes.

Fixes #893.